At that point, you lose the feeling that there are magic things out there that you will never understand and that for the most part everything is just regular old code that regular people wrote.

I don't really remember when I felt that external dependencies were magic, but thinking about this, it explains a lot of the behavior I see on some developers who are very negative about the more challenging parts of the job.

Some of them don't really believe the research stuff we do at work are even possible. They're constantly surprised when other devs finish those tasks. Some don't believe that other devs can code in C++ or Rust, or write parsers, database modules, implement IQueryable in C#, or develop novel algorithms for novel applications.

To them, if a package exists it must just work, and that package comes from another breed of developer that can't coexist with them. I see a similar thinking with AI: now with ChatGPT and GPT-4, there's a hubbub about there being "no reason for our AI team to exist anymore".

I'm not a big fan of working with those developers.

I agree. And it ties into something I often see that puts me on edge: programmers not taking responsibility for the code they put into their projects.

What I mean is that when you incorporate any code, from any source (library, framework, copypaste, etc), then you are responsible for that code and its proper behavior as much as for the code you actually wrote. So you're well-advised to understand it.

That's one of the reasons why I won't include code that I don't have the source code to. I need to understand it and be able to fix it.

The "out of sight, out of mind" approach doesn't really work for code you're actually responsible for.

So the go to for every solution is to find a third party library from a “real” witch or wizard, and follow its basic tutorial. Maybe try to customize it a bit at most.

If something breaks, just start randomly moving things around or copying and pasting more code from forums until it works.

I can’t live like that. I need to know why something’s not working, AND why it IS working. I like stepping through my code with a debugger just to make sure things look right, even when they’re working.

I think the craziest part, though, is just how much people with this “software is magic” mindset can actually get just by brute force cobbling things together.

To me the issue is they assuming everyone around them is like this. I'm totally fine with lack of experience or knowledge, but a co-worker constantly underestimating their peers is not alright.

Where it really stings is when I do something of my own initiative (like, for example, create a transparent API over memoizing and caching some expensive calculation, or refactor some of our common client customizations into their own set of classes so it’s easier to extend) and he ignores it or scoffs at it.

Only to then find a third party library that implements something similarly. THEN it’s presented to me as a “brilliant idea” that we can take advantage of.

At that point, when I say “we” already do this, he usually rephrases what his brilliant 3rd party library does, as though he can’t fathom that I would be capable of doing something like that myself, and clearly I’m just not understanding what he’s telling me.

I think it’s a defensive mechanism for his ego against one of his peers or employees being more capable than he is.

But it’s also not like he can’t learn this stuff himself, he just doesn’t ever put in the time or effort.

For, say, security implementations for authorization and access controls, or even low level HTTP request routing? Absolutely. The goal there is to adhere to something standard and battle tested by experts, and the third party libraries tend to be fewer in number, and of higher quality, with longer term support and clearly defined upgrade paths.

But that’s the lower level stuff, where your special custom needs are superseded by the primary goal of just “doing the one right thing”, or “adhere to the commonly agreed upon standard”.

For all the other things that make an app unique - things like CSS frameworks, UI components (beyond basic, accessibility-minded building blocks), chart drawing, report generation and caching - my experience has taught me otherwise, the hard way.

Being stuck using a 3rd party library that doesn’t do what the client or business needs it to do, having to juggle our own internal patches and bug fixes with updates to the library itself, all only to have the library abandoned or deprecated in favor of the author’s next pet project, really sucks and often comes with a high opportunity cost and a high development cost.

I now consider third party implementations of higher level features (and especially anything front-end) to be something that needs to be evaluated as equally costly as an internal implementation by default, and not favored just because somebody else wrote it.

Maybe I’ve just been unlucky in my experience, though. I also suspect ecosystem makes a difference. The PHP and JS ecosystems are full of poor libraries with snake oil sales pitches. I suspect this is different with, say, Rust.

I’ve mostly worked with Python and JVM languages, which probably explains why I’m less passionate about the counter-argument than you are. Ecosystem definitely matters a lot. VanillaJS is the only good JS framework IMO.

That mediocre dev is a straight shooter with middle management written all over them…

It's a matter of preference but IMO/IME it works better when a manager is actually good at it.

A manager that is supposed to be technical but only wants/knows how to do the management part, and can't make more than the basic stuff won't really fly. I've seen a couple of those getting fired during probation period.

On the other hand, the "bad developer" that thinks packages are magical will eventually settle as an expert beginner in a low-expectation environment. Which is fine.

Dotpeek is integrated into Rider and is a world class decompiler. It also integrates into Visual Studio either standalone, or with ReSharper.

You can also integrate external source symbol servers into your IDE of choice as well that will let you debug into libraries seamlessly.

If you highlight a method you call from external code and hit CTRL + F12, Visual Studio will automatically decompile it for you.

In the case of non-compiled languages, of course you don't even need this step since all your libs exist in source form already, so it was pretty simple for me to step through Ruby library code with a simple debugger and no fancy IDE.

I have a habit of sometimes debugging even horribly abstract framework (e.g. Spring) code when I don't understand what it's doing. That's maybe not the most efficient method, but it does usually make me understand why thing X is not working the way I expected it to work.

I think the real skill then is to learn to navigate big codebases in few days time than taking a few weeks and then feel dejected by the time spent and still unsure.

I often feel ambitious for such endeavors but navigating big codebases take time, any tips?

More importantly is to use an IDE with a good fast global search function and get comfortable with it. At least for me, 99% of navigating a large codebase is global search.

You can goto or peek definition in VSCode. And the find tool has the option to find all occurrences throughout your project.

Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.

We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source.

As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up.

Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.)

The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!

This was and is quite common in any blue-collar field where works don't always have the money or time for a brand new jawn every time something goes wrong.

I love estate/yard/garage/barn sales and going through the tools and reading the tales they tell from their wear patterns, field repairs, revisions, and hacks from their owner.

Case in point, here's a tool which has gotten multiple leases on life through modifications. https://youtube.com/watch?v=oTA513ttrbQ

For example, I have a graphics project where screen tearing suddenly started appearing although my code didn't change, and the tearing wasn't there before. Is the issue in Skia, OpenGL, the graphics driver, the Intel or NVidia GPU, or the OS? Or is it some latent issue in my code that started showing up because of a change in these dependencies? Or is it some other complex interaction between multiple dependencies? I couldn't possibly know, and I actually don't think there is anybody that actually knows. And there is zero chance I could ever figure it out. I mean, it at least appears it was a driver issue as after some updates and a reboot it just went away, but there is zero insight into why or what actually made it go away.

If I modify a plow because some part as originally designed was flaky and constantly broke, you usually know to a pretty good degree why your fix works.

In software, the abstractions are such that it is practically impossible atbtimes to understand.

Sure, welding back on a hardpoint that broke off a plow is concrete and obvious (maybe that's analogous to fixing a broken dependency that got renamed), but there are other fixes that definitely fall under "I don't know why it works but it works". I've had electrical gremlins and fixed them by grounding something that looked like it ought to be grounded, and was grounded when I tested for continuity, but nonetheless was acting floaty. It was probably a loose connection elsewhere in the system, but I didn't know that for sure, nor do I even know that it was the problem in the first place.

Software definitely reaches insane depths of complexity, but again, if you can dig down and understand the abstraction well enough to attempt a fix, and the problem goes away, isn't that good enough? The real difference is mechanical systems typically only have a few layers of abstraction, while software has dozens to thousands of layers of abstraction.

A mine site usually fixes its own tools used to do their job, they usually fixed things they've purchased to use that are broken or become broken, is that not the same?

On a mine site, the job is to mine and process minerals. That includes engineering a mine using products that eventually fail over time and need fixing. As part of that process an automotive electrician may need to fix the electronics on a vehicle that have become faulty or damaged.

Mechanics and engineers need to inspect, rebuild, and fix the tools they are given to do their job. The difference is that yours may not work up front, whereas these tools need maintenance over time.

The difference between most professions and programming is that we have open source. The equivalent of that in the real world is getting blueprints to build our tools and then building them ourselves, with no guarantees.

Very different situation

I've also found that the software industry obsesses over tools more than any other industry

For React devs, this means learning how React actually works under the hood.

The other thing I find is that big libraries are either mostly dependency bloat (as implied above) or dealing with a hard domain problem. If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent.

But this doesn't change anything of the programmers problem. If I stumble on a bug in a physics libary I am using for a game, I cannot just jump right into there and go fixing things. I mean I can start doing it, but at the cost of not getting anything else done for quite some time.

There are lots of hard domains in programming. Cryptography is hard. Networking is hard. Fast rendering is hard. Efficient DBs are hard. OS are hard. Drivers are hard.

You can maybe fix a trivial error in such libaries, but everything else is usually a (big) project on its own.

Additionally, once you recognize that you can also recognize if you’re dealing with incidental complexity (e.g. poorly thought out/designed code) and inherent complexity (e.g. physics calculations). The former can be fixed, the latter cannot. Knowing the difference saves much pain.

In some ways it's terrifying, as I know a lot of my work is trash.

On the other, recapping everything I've achieved myself, with no CS degree and nothing but Google to guide me has made me feel oddly proud.

From doing the recruitment and chatting to my new colleague, I've really gotten an understanding of how small a role most devs in "serious" set ups have. I've learned a really broad range of skills because I've had to.

There's always going to be more things to learn, but looking back every once in a while can put things in perspective a bit.

> There's always going to be more things to learn, but looking back every once in a while can put things in perspective a bit.

Well said! Thank you for reminding me of this.

Over the years, though, as I saw more and more code written by programmers I respect and from companies I respect, I noticed that mine was no worse than theirs -- and I realized that my skills were, at the minimum, just fine. Warts and all.

(Edited to swap "mine" and "theirs" to be what I meant to say)

Humility is a wonderful thing, though, and you can maintain it regardless of your skill level by recognizing the truth that no matter how good you are at anything, there will always be someone better than you.

I personally get nervous when I'm not doing something I'm a novice at. It means that I'm not growing.

That's what worked for me. By the time I was hired for real, full time coding work I had already done lots of C-64 Basic and assembly, x86 assembly, C in DOS and Win32 and had been reading DDJ for years. When I discovered the hopelessly abysmal code that supposed veterans had built their careers on I knew I was worthy.

A simple CRUD app is magic to the average user, if it does something they haven’t seen done in software before - and that could be as simple as some calcs in a custom domain.

The first customer who tells you “this is great”, if it’s anything like my experience, changes everything.

It also helped that some of my early forays were to clean up code by a guy ten years my senior which was rammed with bugs - fixing those one by one was satisfying and helped me earn trust with my team and in myself.

There's a nice concept in theater that says, effectively, "if you blow a line, don't broadcast it to the audience." The subtext of that is, simply, the audience doesn't know any better and what they don't know, won't hurt them.

By and large, this applies to many fields, and certainly to software development. The users, in the large, do not care over a huge amount of stuff that we, as practitioners, care about.

We're in a results business. The users care that they get the report they want or can update the data they're supposed to. How that's done, in the back end, is filed under "blah blah blah".

The reason this is important is not as an excuse to do crummy work, or to not be passionate about the minutiae that consumes us, but to be cognizant that as long as the end result is functional and capable for the user, it's OK for the processes that get to that point to be a bit messy. Don't beat yourself up over a lot of the things we beat ourselves up, or criticize others over.

Ship. Get your code in front of users, interact with them to make their experience better. We are in a service industry. Strive to be better, but you only get better by shipping, and moving on.

The confidence is that, for the most part, "it's just software" and you can fix it. You can change it later. You can correct mistakes.

Another saying is that you're not a professional until you've lost production data. Thankfully in our work, loss of production data rarely kills people, in contrast to the path of becoming, say, a doctor. If you are in an industry where people can be hurt, then that's going to be more rigid, for obvious reasons.

I have lost data, I have been SCREAMED at by clients, I have stood under the withering "What has just happened here" glare from management. It happens. Ah, the warm camaraderie of being thrown into a data entry pool to help rekey some of the 6 months of data you destroyed. A cold truth in our business is that it has to happen, as we only learn through practice, and through practice, sometimes we miss.

But to do that, we have to ship. We have to get the work out there, "I don't test often, but when I do, it's in production". Sometimes you just got to open the firewall up, let the traffic in, and see what happens.

A cynical view is the that the more we ship, the more we learn what we can get away with. There's a truth to that as well. We're all victims of not listening to "you're not going to need it". For all sorts of values of "it". But that doesn't mean we can't keep those concepts close, practice them as best as we can (because, truth is, sometimes you do need it!).

Through the work, and shipping, you learn the balance, and get more comfortable with it.

When I was new, I was insecure about seeming like I didn't know certain things and wanted to "prove myself", so to speak, so I would keep my head down and try to figure things out for myself.

Over time I've realized that leaning on others with more expertise than you is how you learn and grow, and asking questions and collaborating with others does not reflect poorly on you as an engineer (quite the opposite in fact).

These realizations are what have boosted my confidence - I know that if I'm ever working on something that I don't know how to do, I can go talk to someone who does know and learn something new. If you don't work somewhere where this is possible (i.e. you're always the "smartest guy in the room", as they say) then your growth as an engineer is going to be limited.

With just NAND gates and D flip flops as primitives, building a full 16bit ALU, then an ISA for it, an assembler, compiler, operating system (with memory mapped keyboard and screen) and interpreter. Then writing a Sudoku game in that interpreted language, and seeing it reduce all the way to just bits. And then running it on the simulated computer.

Really have a holistic view of what actually happens when I run a computer. Also demystified compilers for me.

Second thing was learning concurrency control, transactions and all that. The Eureka moment for me was understanding that git and databases solve a similar problem. After that, both tools lost their mystery.

Second last but not least, making web apps! A low entry barrier way to make things anyone can use really boosted my confidence.

Last but not least, learning the statistical underpinnings of machine learning.

Of course, I'm still in University so I am by no means an expert at any of the above, but even at my level these things really help with knowing your true place.

In the late 90s to early 2010s it was fashionable to think of code as a graph of dependencies, and as long as you honor those dependencies when changing the code you would be ok. This is simplifying but pernicious POV IMO - reinforced by the zeitgeist that code is truth and comments (in code or otherwise) may not be. This is a cul-de-sac.

Unless developers see things as nouns or verbs, they don't acquire the ability to scale and see the bigger picture, because there is nothing to hold these smaller entities and connections between them (O(entities^2)). The concepts are the bags. Wish someone would explicitly teach us these things, because, sure as hell they didn't teach it in college.

May be people who have a liberal arts background are good at seeing these things, because one of the things they explicitly study is perspective, framing etc. Engineering is quite limited because we don't explicitly study about that.

For me, I just worked ridiculous hours to compensate for the suckage, read books, listened to podcasts (when that became a thing), programmed at home, read through the code, looked at the code history (code archeology). Eventually you get good and you know you’re good because you can compare your output to those around you.

The secret to surviving the early stage is to recognise that a career is a marathon, not a sprint, and gain joy from the small incremental improvements you make. Everyone above should have worked with plenty of juniors and are just looking for people who are getting better.

A close colleague - a team lead of a different team who I had worked with a lot, went to a couple dev conventions and meetups with, and agreed with on a many facets of software dev and life in general, signed the card as so:

> It starts with a dream. Don't stop.

Many many years later, I still think about it often. Sometimes, all it takes is a little faith.

It just all makes me feel like I don't belong in the field. It's all so overwhelming and complicated, and any attempt to try to make something more simple or documented is fruitless if even accepted. People just can't see to be able to wrap the idea around their heads that one thing doing one thing is simple and not "tedious" or "verbose".

The reason why my confidence lowers is that everyone else is seemingly okay with all of this and continuing along the trend. Meanwhile, I feel like I'm just continuing to participate in building giant balls of mud that just barely work and are just barely understandable. So there's an impedance mismatch, and I face it so much, I just have to wonder if it's me, that I'm not smart enough to push through all the cruft or figure things out or just don't understand how to design. Thus, the low confidence. It's just all very confusing.

I would be somewhat suspicious of anyone in software engineering who purports to having figured it all out or having confidence in the field.

>The amount of politics, power jockeying, engineers who hide behind decisions as if they were technical only to be highly personal preferences, how many people reject simplicity and prefer complexity while calling it simple, lack of documentation, etc.

Learning on my own and participating in online communities, receiving feedback and coming up with project ideas led me thinking that this field is creative and people treat it as a craft. The hiring process has you either do leetcode, show off your projects and talk about them or both.

Given the above, it's easy to understand why someone would expect to see the same in the job. But instead what you get is completely the opposite. My first job felt like I joined a restaurant that actually is a fast food joint, and the metric of performance that makes people happy is how many burgers I can churn during a sprint. Documentation? Can happen later. Testing? Slows us down, test by hand.

And on top of that I had teammates who refused to use the phrase "I need help" and "I was wrong", almost as if it's a sign of weakness. I don't know if it was their upbringing, culture or just because they had to demonstrate perfection to show how worthy they are of their position, but it sucked and I ended up spending more time tiptoeing around their ego than being an actual junior engineer, so I had to quit and recalibrate my career goals.

If anyone reading this just want to write bash scripts that don't violate fundamental principals, there are jobs out there, but they're typically low paying and academic

This is a good point and something that is indeed requires a lot of care and thought and experience to tackle properly, but I think it strongly hinges on the assumption that software just does a thing, so to speak. Whereas I personally view software as something that does a thing but at the same time as something that is also a communication system and encoding of domain knowledge. So if the communication and encoding parts of the software are missing, and all you've got is it doing something, then in my view, the software is leaving value on the table over the long term. Poorly tested, understood, documented, and specified software will have waste products over time, siphoning value away. But it does so much more quietly, but in no less magnitude, than when software is not doing what it is supposed to be doing.

It's a fundamental systemic issue that's why we see so many tech companies produce terrible products. But we (the programmers) have no ability to fix the shortsightedness of the American financial system.

My confidence as a software engineer comes from the gratitude of my users. Giving them something that makes them light up and say "I had no idea I needed this." I've worked in many organizations where layers of bureaucracy smother that joy. Having a direct line to my users is incredibly motivating.

Many comments touch on the "do it for the users" mentality and I'll add my own take. There's a book called "The Science of Drawing" by Harold Speed. It's a pretty rigorous dissection of drawing written in 1913. However, despite its clinical writing style, the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction. Dissecting art is only as useful as a means to produce more of it, the emotional communication is the actual core of the medium. Software is very similar in this way.

> It sounds like you have a commitment to excellence not shared by your peers.

Just to be clear, my sentiment is one built up over time and experience and not directed at any one company or colleague. There are kernels of this everywhere though. I'm also a part of it all. I've definitely made things more complex than they've needed to be, but I do attempt to learn from that and revisit approaches.

> Giving them something that makes them light up and say "I had no idea I needed this." ... Having a direct line to my users is incredibly motivating.

This is a really good point, and thank you for saying that. Your advice here is very helpful. I have had the most fulfillment when having a direct user being able to use software I've worked on to do their job better.

> There's a book called "The Science of Drawing" by Harold Speed.

Thanks for this book recommendation! I'm going to check it out.

> the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction.

Even though it was not intended this way, one of the greatest complements I ever received on software that I personally and solely wrote was someone opening up my code and saying "where's the code?!" in a completely bamboozled way and also a way in which they were legitimately worried if it actually did anything. Haha. They were used to hodge-podge collections of code stuff into a single file doing absolutely everything under the sun. So when they opened up my code, they were legitimately bewildered that everything was modularized, componentized, etc., and for a half minute they were suspicious that there was even anything implemented. It was confusing to them that things were labeled simply as "do this specific thing" (as an abstract example), and it actually just did that specific thing rather than a block of spaghetti code doing something but god knows what.

It’s all cyclical. The decadence today will eventually give way to another recession, and we’ll build something better from the ashes.

I’m also growing increasingly disgusted by the state of the industry. Things weren’t so messed up 10 years ago, but salaries were also not so ludicrous at the time. I suppose I should be careful what I wish for, but I’d appreciate some disruption right about now.

I could live with apathy towards documentation, but it goes beyond apathy. There is often outright hostility to anyone who “wastes time” writing documentation or doing design work. Agile grifters have absolutely ruined this profession.

It's fine if you're collaborating with someone else or a team, as long as there are some good-sized chunks in there that you can point to and say "I did that part." Your customer might only be a different team in your company. The point is that you created something that had an impact on other people.

PS I'd also suggest: Take some time and build something small in assembly language. Getting even a bit of a feeling for how the CPU actually interacts with memory and registers and math and branching will give you a completely different perspective on higher-level languages.

One was taking my first college CS course. Just being forced to work in depth with indirection and write algorithms set me up to make all sorts of things, even though I did not go on to get the degree.

The other was to realize, after a few years, that code isn't an edifice - that is, you don't progress through it linearly to a solution, as tends to be the case in school assignments. To solve a production-grade kind of problem, you start by making an incorrect solution that you understand well - the proverbial "start with a hello world". And then you iterate over that to generalize and make it produce more correct answers. The bugs reflect a lack of understanding of the system, and architecture strategies tend to result from knowing that nobody can understand the entire system, thus you design in some constraints and safeguards to enable more complex ideas to build on smaller ones without that understanding.

This process also meant learning to reject "blogpost-driven development", which was a common genre back in the 2000's of people doing some career-making by making a blog about some cute idea they had about best practices. Naive me, I tried testing out every one of them, and eventually, through painstaking reduction, learned that mostly, you have to invent the best practices according to the problem domain. If you can get a direct answer by not writing code, that's a really, really good idea, hence I try to usher more of my work onto paper or into a spreadsheet now.

That being said, there are things that boosted my confidence, such as getting offers from FAANG. But it was temporary. Software engineering still seems like a tedious and hard activity. And it's getting worse now that everything is distributed.

They came straight from a bootcamp and for months felt like they weren't getting better, were constantly asking questions about stuff. It only finally clicked and they gained confidence when we got a second out-of-bootcamp developer and the first person was the one that was constantly answering their questions. They hadn't realized how much they were learning because their only comparison had been those of us who had been there a lot longer.

Using a REPL-based language like Lisp (which I learned from reading advanced Lisp textbooks) for several years before I worked professionally as a programmer enabled me to dive into complex, underexplored parts of the (Python, C) projects at my first job, which meant I basically owned some very important parts of the stack.

Reading and applying ideas from Unix sysadmin books enabled me to be comfortable jumping around the OS very quickly, giving me a speed advantage even when the computer I used was pretty underpowered, relative to my colleagues, early in my first job.

It's taking on a challenge big or small and seeing it through no matter what it takes. You'll get stuck for hours, days, sometimes weeks, you'll get frustrated, tired, annoyed, but you just refuse to give up and eventually get it done.

Those are the moments that bolster your confidence and you realize you are capable of achieving seemingly impossible things.

That confidence of "sure I can figure it out" is what you need to feed and grow as a programmer and probably in many other professions.

Best way imo is to pick reasonable small contained projects, and slowly ramp up and take on bigger challenges. If you take on too much, shelve it, do something smaller, then return to it later.

It takes a lot of time, effort and perseverance, but as long as you keep going you'll get there in the end.

At that time I worked with some enterprise software on Windows, and any particular setup was so fragile, that it caused anxiety to touch anything and learned helplessness preventing experimentation. It didn't help that built-in diagnostic tools on Windows in the XP era were virtually non-existent.

Linux VMs in contrast were (and are) disposable, have all their guts exposed, and CLI is your only way of doing things. You're welcome to experiment, and basically forced to automate.

This seems mostly true in my personal life. As a hacker, it explains my 5 year obsession with minecraft and gmod in my teens. I got deep into gmod e2 and then actionscript3 (RIP). It also explains why some mechanically gifted people I know don't "get" the flexibility of code, despite their intuition for systems. I think it takes a certain conviction to modify and extend abstract systems. Problem diagnosis is not obvious and can be very frustrating. But the dopamine hit of seeing things work together is enough to keep me going.

Overall, my hacker foundation is built on a never-ending loop of frustration and desire. Frustrated things aren't working with a desire to make things happen. I didn't program professionally until recently, but I instantly understood the mentality. I'm grateful for the wisdom my career has given me to pursue it.

Oh I didn't mean that at all, they could like engines too or even more, just they aren't turing complete (unless you mean like babbage machines or that crab gate machine which I assume most children wouldn't create or have access to). I meant that usually these proto-hackers as children at some point will have accidentally found a turing-complete thing and played with it when they were children before they learned programming officially, even if they like other things more. Then the moment "the first step from being a tinkerer to being a skilled craftman" would come when they learn that programming is a thing and they find it's actually so much easier than the convoluted logic systems they were making themselves.

I was just learning the relevant languages and jobs, so their response gave me confidence to keep trying things and learning.

This is absolutely IT! Everything else is secondary. Nothing boosts a noob's confidence as the fact that his boss trusts him to deliver on the project and gives him the responsibility and positive support needed to do so.

By completing stuff. Making things that actually work in the real world.

(and my problem in hindsight was rather overconfidence, just because I made some small games and websites, I considered myself already to be a programming master)

3. Being able to use version control. Having the confidence that my work cannot be lost was a big boost.

4. Having some understanding of what non-developer stakeholders care about.

Went away to college for something completely different, psychology, but when I got home and started applying for jobs, nobody would hire someone with a bachelors in science only.. so I decided to pull out an old trick of mine: I would apply to the programming companies too. Got an interview. Got the job. Even though my math skills were horrendous.

The confidence in my programming skills came a few months after they hired me. Til then, I'd been working on building various little programs that had no real purpose. A ping pong came, a slot machine, etc. My tyrant boss had me go through training to use various functions in Visual Basic 6. Some of the most valuable ones were using arrays and collections, which had helped me understand databases later on when I was learning PHP.

I was developing software for an autobody shop. I really couldn't wait to work "in the main program" but once it was established that I was ready, that's when the confidence started taking off.

About 6 months later, his customer base went from a few hundred to a few thousand. My job was to focus on the UI, making it more user-friendly and easier to use and fix existing bugs in the program. I loved and hated that time of my life because it led me to meet a wonderful woman, yet I was going through hell everyday for that tyrant. Fortunately, I took what he taught me and used it to further establish my career elsewhere.

I joined as the "person who will teach them how to use AngularJS and rewrite the Ember app with it". This went pretty well as we (mainly myself) rewrote the app pretty quickly after months of them struggling with Ember (I didn't use Ember, so I don't know if Ember was so confusing or they were just lazy to learn it will).

After that, I started looking into the backend and I was able to contribute to the company's success. When I had to use Cassandra, Kafka, Symfony, Ruby, Puppet, etc, I'd watch hours and hours of videos, read documentations until I knew it "well enough".

After some time, I noticed that quite often I knew the subject better than my colleagues and I could come up with solutions and implement then on my own.

This helped me realize that these technologies can be learned and it's only a matter of determination, dedication and patience.

I was smiling reading git here -- the above happened before CVS was invented. I am old.

The chief one, I think, comes from simply having achieved enough challenging problems to the point where one knows that, even if their solution isn't perfect, they can figure out basically anything. The overwhelming majority of programmers can get to this point eventually.

Confidence also comes from the eventual realization that, with few exceptions, the majority of programmers you think are "better" than you are really aren't objectively better. They may have a fancier title, a bunch of GitHub stars, have given presentations, or maybe they've written a book, but this doesn't mean they are a better programmer than you. It might be hard to understand as a novice, because virtually every novice is going to feel inferior for lack of experience. After having gained sufficient experience, to the point where there's seemingly no problem one can't solve, it may become obvious that these programmers one once viewed as elites actually just broadcast their craft in a way that gives them higher authority; I stopped viewing most programmers as being better or worse than each other because I've witnessed enough problems caused by the clever solutions of senior and staff developers. It's just much easier to blame a junior engineer's solution when it doesn't work out. This isn't to say that more seasoned programmers aren't worth their salt, but there's almost never something they have that you can't have, and every programmer out there writes bugs all the time!

And finally, seeing the tech hype come and go over a long enough period of time can eventually bring one to the point where they look back on methodologies, frameworks, and design patterns they were once introduced to and come up with the original thought of "You know, I think that X was kinda bullshit to begin with." I think it's really unlikely that a programmer can have a 20+ year career (or even a 10+ one for that matter) and not come to some conclusions like that. Though it's easy for a novice to get caught up in the churn thinking they've got to learn all the things and feel inferior for not knowing it all, experience may someday teach the programmer that most of the churn was hype and that their own ideas on how to program effectively probably would have worked just fine.

I would say that I gained my confidence by just trying enough times and gaining experience.

I feel stupid all the time. I don't know anything about almost everything, and the little I do know about, I'm sure it's less than what I think it is.

I don't know how a GAN works. I haven't the faintest clue about machine learning. Someone asked me 'hey, you have a CS degree, tell me how ChatGPT works.' I couldn't answer that.

I never took databases in university either. I am mediocre at algorithms—it takes me 45 minutes to an hour to solve a supposedly 'easy' problem on LeetCode.

I still use Windows and Visual Studio, because that's what I grew up on. I don't know how to use Vim besides hjkl and :wq!.

I don't know HTML and CSS. I've looked at the more popular blog posts in the recent Ask HN thread. Everyone discusses things I've never even thought about. They have custom blog engines they wrote from scratch, that actually work.

I know a tiny bit about computer graphics, but I have hardly written any shaders. I also know an equally inconsequential amount about parallel computing, and even so, I dislike any problem that cannot be easily and embarrassingly parallelised because I don't fully get synchronisation and acquire-release semantics.

I don't know if anything can boost my confidence at all. I have a tendency to ingratiate myself with people a lot smarter than me, and as a result the large majority of my friends from university are now working at HFTs earning five digits a month.

While I certainly have learnt much from all of them, they just makes me feel even more stupid—through no fault of their own, mark my words.

Not sure if this will ever go away, but I believe the feeling of stupidity will only ever increase as I realise just how much I don't know.

There will always be people that are smarter than you. Perhaps even better at your job than you are (currently) in every way. Dont let it get to you; there's nothing wrong with not being the very best. There's also the old saying that "comparison is the theif of joy" (idk who said it, but it has truth). The hardest part is accepting it's ok not to know something; you can always learn it if it interests you.

As for tooling, if Windows and Visual Studio work then great. Vim is just a tool.

Did you mention to them that they're a clown?

Starting out with intranet PHP was a daunting task, had to get the system setup (Apache, PHP, MySQL) write the code then mess with permissions, etc. Getting that first response back that it worked (or at least kinda worked) said to me you can do this!

back when I learned BASIC 20+ years before that, was the same thing, Back then, I started by either entering or loading a simple program and changed stuff and realized I can change this and the silly experiments in changing values and commands gave me more encouragement to learn and try more.

Early success even if stupid, is big positive reinforcement. If you can't get to Hello World because you are stuck in language/IDE configuration, you aren't going to get fer. If you can get there quick and realize the potential you now have - all that low end stuff becomes a desired necessity to make your magic happen.

Then one day I was at the book store and stumbled upon W. Richard Stevens Advanced Programming in the UNIX Environment. I spent hours reading it while sitting on the floor right in front of the empty spot on the store’s bookshelf. It taught me that much of why I was doing was right and helped fill in a bunch of gaps. A couple weeks later I was back with half a week’s pay to take it home with me.

Which is why I am not sure I agree with the view that dynamic languages are good for beginners, I think beginners need a third wheel, an IDE that understands your code and can tell you with confidence that you can't do "a+b" in this context. For that it needs to know what a and b are.

For the confidence? It was working with others. The first job I had I got to sit down with one of the company's programmers as part of my on boarding and watch him work through tickets. After I saw just how flawed everyone was I felt a lot better about myself. I suppose that's a weird thing to say: Oh he was pretty shit, so I shouldn't feel bad about my poor performance...but that's not the point I want to make really. More that, it is wrong to compare your efforts to learn and grow against the final product of others. Once you sit down with the experienced devs and see how they shape and form the product and all the bumps along the way it doesn't feel so bad to struggle on your own.

Ultimately the skills that I honed that gave me the best boost in confidence were not really the direct programming parts where I put letters and numbers in files. It is the debugging. Understanding how things move and where to look for problems makes me feel like I can solve any problem with the right tools.

This helped me because I had to learn requirements, talk with people, understand dependencies, and not make people’s life harder. And I had sort of a value to smart seniors as I would maintain stuff that was hairy to change and not break it.

I also spent a lot of time on nights and weekends volunteering with the network people and hardware people and firewall people to understand how those components fit into the architecture.

Someone coming around with a pull request going "Heyjo. I needed new X in your project. And, I looked at it and X and tests for X just slotted right in there. Can you take a quick look if that's right?"

I consider these easily and obviously extensible workhorse code bases my best work, even if after a certain point, I may have built like 10% of the thing and shouldn't consider it my thing anymore.

Also in school we had to do some big projects like make a virtual machine from scratch and implement things likes call stacks, threading and memory management with our machine op codes. Doing a big long project that really pushes you out of your comfort zone is a BIG help and also can be an opportunity to do something really fun.

Edit: I left out the important role of asking questions, talking with others and even taking the time to compose a forum post or issue on github when it seems that I’ve truly exhausted all my options. Bottom line is, when I took my time and really tried my best to learn something new/difficult there was always an eventual breakthrough and consequential boost in confidence

books or classes didn't do anything for me until i was able to actually apply the new things learned. (for me learning is problem oriented, i take a problem and learn how to solve it)

also as a novice i found building a project from scratch daunting, because there is so much stuff to do before you can get to have some actual functionality. i prefer either to start with something very small but with some usable functionality that doesn't take long to build, and then add features until it is completed, or take something already working, and build upon that.

when i learned lisp i took the example project that was in the book towards the end and built it into the tool i wanted.

though i think test driven development can help here too. as each passing test is a success. so write a test, pass it, continue, until you have something working.

Even the most incredible 10x engineer has at some point done the stupidest thing you can imagine: deleted a prod database, set a server on fire, pushed that one simple single line fix that took down several downstream services, and so on.

Those stories and learnings are the ones that turned the stubble-chinned doe-eyed juniors of yore into the full-bearded crusty Gandalfs we love, that seem to know everything and solve problems in a finger snap.

Seriously, getting your code out there into the hands of users is the #1 confidence booster for all developers, everywhere.

There is no better feeling than to see the completion of a unit of exchange between the compiler and the end-user.

Another thing I do, is read, read, read. I have tens of thousands of repositories that I've checked out and had a good read of, over the decades. This is an extraordinary way of learning new things and gaining competency.

Now, the other side of that coin is realizing that, yes, I’ll eventually figure it out, but some of them will just be absolute misery to work through ;)

But eventually you emerge on the other side and you move on.

Getting over the whole idea of beautiful or perfect code. Realizing that code is a medium of expression and that there is no single right way to do everything. Beginning to think of code as a clay-like medium rather than literary prose that needs to be beautiful like a cathedral.

Seeing how some of the most experienced and productive programmers do things in extremely simple straightforward ways, with no unnecessary cleverness, indirection, abstraction, or anything like that.

Seeing how linus torvalds is right. It's really all about the data structures. Once I understand the data structures and their relationships, I can understand any system. Dispelling the myth that some things are just "too complicated". Almost every problem or system I've ever come across can be reduced to a page of data structures.

Realizing the power of fast feedback loops. How just about any requirement or problem can be expressed as a test case. And that once you have the test case you can fix anything.

About four years after he reviewed a series of changes me and two coworkers put together to rework this handling.

Also for me (very specific to people starting in late 90s) realising I wasn't the only person that thought forced 'object oriented' programming was bullshit. 25 years later this style has gone out of trend, and a lot of people realise that Alan Kay meant something more like the actor model than Java.

I started as a full stack co-op, but 95% of the work was React. Then we wanted to implement Cypress to do fully E2E testing.

That led my to dig into CI (Circle), Docker, AWS, Redshift, Security Groups, networking. To make the test truly end-to-end, we had to spin up about a dozen containers, several databases, connect to Redshift. All those things were very, very strange to me and very scary.

Luckily nobody wanted to touch those things, so the task was up for grabs and my manager allowed my to try (since I was a co-op, there was not a lot of pressure to deliver other projects).

When I was done I realized that I was not just a JS/React dev, but I could dig in to other complex things and figure them out. My confidence shot through the roof and after that I wanted to work on all big projects available. Ended up switching to a backend team that does completely different tasks from my original one.

But I saw it like me against the machine. Since I was youn I wanted to be an inventor. This tool allowed anyone to "invent" any software coming out of the inventor's imagination. It just required a computer, and the inventor not giving up and using his brain. I could do that. I liked the challenge.

Be a tinkerer, have fun! Discover things on your own. Dare to be stupid and do whatever stupid thing feels right. You don't need to follow some pre-programmed plan.

Programming is all about problem solving. You solve one problem, good. Now you will have another problem. No one guarantees you will solve it nor how much effort it will require specifically for you to solve it. And maybe it's the wrong problem to solve. But you will end up figuring all that out, and then you will feel accomplished and willingly hunt the next problem.

Follow a bit some tutorials, then play around with code, try to make something, its ugly AF so keep trying until it's no longer horrible. Rinse and repeat.

How to know when you are "a skilled craftman"? As long as you look back 6~12 months and think "that was ugly! I'd do it differently today" you are learning (good!). Otherwise you have become a skilled craftman (also good!) or are stuck, but at least in my case it was obvious when I was actually stuck and not improving.

Note: this "playful learning" didn't work for me with learning a language (prob need a base good enough to just keep the ball rolling) nor with piano (probably because painting is satisfactory from the first stroke, but piano is only after you can actually play stuff).

For me, what really boosted my confidence long term was getting yelled at by people who actually knew what they were doing because I sure didn’t. But that ended up being more of a bathtub curve of confidence.

It was while I was taking CS50 online that a programmer left the company where I'd been working (in a non-technical position). His manager was scrambling to re-distribute his workload, and knew that I'd started taking an online CS class. When he offered me some easy entry-level work, I'm sure I would've said "no" just months before. That was the exact moment when the class made a huge difference.

Now I have a handle on the sorts of things that can go wrong / are going wrong in the real world, some earned confidence in my ability to fix them, and general upward trend in my ability to anticipate and prevent them during development. On the other hand I no longer have any trust at all in code that has not been put through real-world usage or where I don't have access to feedback from real-world usage. Reality is much better at generating interesting test cases then we are.

1) I can figure out issues in other people's implementations.

2) The best solution may not be the best solution for you, and my hunches on optimization might be correct

3) It's fun to look like a wizard to your peers

My first job as a programmer I was tasked with building a replacement for an existing system. I worked by myself, and was just told to ask if I had any questions. I reported progress once a week by giving a percentage complete- for the whole project. That’s it.

The next job I was supposed to be a consultant. But I was so clueless- I didn’t know what I didn’t know. Eventually I was canned.

Finally The got somewhere that had a defined agile process- I started getting work done and was even able to mentor some people. Then I flourished and now I’m pretty comfortable with where I’m at.

If it’s not going right, the position might not be a good fit.

I knew I could outwork everyone and brute force being a better programmer by a function of continuous improvement through hours of work. (btw I was wrong, there is always someone out there that will outwork you...and they will be smarter than you, but hey it made sense to me).

I didn't realize I made it until

a) People would recognize me in meetings because of my code

b) New programmers started to ask me for advice

...now I'm in the Sr Devs, Tech Leads, and Lead Architects ask me for advice level. Honestly, I still have the same attitude, if I work effectively, I can keep getting better. Notice that I remove the "work harder" part.

Sounds like a joke but really, I felt super green until suddenly I didn’t. I didn’t really figure anything specific out, I’ve just now seen enough problems that I am confident I can work through whatever I run into.

Few notable things were the first time writing a ray tracer and seeing it work, writing a small emulator, writing a lisp etc. A lot of low level stuff. Learning what executables are made of on different operating systems, and so on. When you're going from not really understanding half of the stuff you use to building some of it from the bottom up, that was very valuable to me.

Also realizing that a lot of people write really not all that good software was another big point.

It exposed me to _other_ people’s knowledge gaps, and made me realize how many things I actually knew and understood.

Seeing shapes collide, bounce, roll, and understand exactly what was happening in the code I wrote was a huge confidence booster.

Start on real projects as soon as humanly possible, even if they're junk to begin with.

We don’t let junior devs do this now because programs are huge. We throw junior devs into bug fixes on large existing code bases (which are often not well architected, full of tech debt, etc)

There needs to be a step between the toy projects in college courses and the million+ line code bases.

Building, releasing and supporting small apps successfully, interacting with users, making changes they want and actually delighting them gave me a huge confidence boost in my early career.

We do a disservice to junior devs now.

At the first company that I worked for I quit after a week because everyone took a task and worked for themselfe. None developer had time to explaine something to you and no documentation.

Also, learning Git was incredible to my confidence in modifying code.

Also, using state of the art IDEs to be able to navigate between my own and third-party code removed pretty much all of my anxiety when dealing with code in general.

1) Ignorance. Knowing just enough to be dangerous was great against analysis-paralysis.

2) Positive feedback from clients. Clients didn't care about my spaghetti code. All they saw was a solution to their problem. That was very rewarding and made me confident. Well, at least until a senior dev took a look at my code and rightfully destroyed my confidence with not-so-polite suggestions.

It made me realise that good engineers don't have any mysterious unknown tool or advantage, they're just relentless researchers when trying to solve their problem (i.e. using Google, Wikipedia, API docs)

It kind of puts into perspective how software works.

People who believe they are skilled can fuck shit up on a much bigger scale because they are a bit too confident. In reality, almost all code is crap. Understanding in what way your code is crap is healthy and useful. Believing that your code is good is not healthy.

When you see your code in action in the real world and know the impact it can have, you gain a new respect for developers who are conscientious about their work, and also that software exists to make something else function.

For me that was when I crossed the line between merely tinkering and actually crafting something that could stand on its own.

That you don't have to know everything and if you're dealing with legit people, they'll be totally find with that and even expect it.

Trying to lie and say you know everything or say you're a 9/10 on every other odd skill/language will put you into a terrible place.

It was also a great reminder that "good enough" is just that.

More recently: Realising that the two senior guys who had been there for 20 years had basically created an incomprehensible clown car of spaghetti code that not even they understood.

Eventually you get enough general knowledge to pick up almost anything and figure it out.

There is no glorious or inglorious software. As long as it benefits users it's good.

Good quality code will come naturally as you will be faced to complicated problems.

Also, do not be scared to write things from scratch.

There is so much objectively terrible code out there. Not only does it exist, but it actually generates revenue. I recall being simultaneously amazed and disgusted.

and

Demo a wireframe in a gui builder to a visiting suit without him realising that it wasn't a fully-developed application.

You’ll gain confidence when you realize you can just hack away until it works and that is OK.

if the capability is the question, well i don't have any answers. 10 years in and the imposter syndrome is still strong.

In it, he describes "The Dunning-Kruger Peak," followed almost immediately by "The Jon Snow Trough." After these extremes, our confidence and self-appraisal starts to linearize.

I cannot say enough about being on teams with experienced engineers, and writing stuff that actually ships (as opposed to disappearing into an "Out" box, and we never see what happens to it).

WFM. YMMV.

[0] https://arstechnica.com/gadgets/2014/10/smartphone-camera-vs...

Naivety!

Ignorance!

Hubris!

And all of that has given me NIHilism!